Domain based authentication scheme

ABSTRACT

In one example, a system for authenticating domains operates by authenticating a first domain and the extensions that make up the URI of an initial or primary Internet network call. Thereafter, the system can enable the owner of the first domain to make assertions or statements about additional domains and URIs that make up the rest of the web page, session or application.

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication No. 61/116,604 entitled “Authenticated Domains: GeneralizingAuthenticated Identity in the Internet” filed on Nov. 20, 2008, which isherein incorporated by reference in its entirety for all purposes.

BACKGROUND OF THE INVENTION

Some existing authentication schemes for web pages rely on CertificateAuthority (CA) digital certificates. In these schemes, a CA digitalcertificate is installed on a server that stores content for atransaction page, such as a home page for a domain. When a client suchas a browser attempts to access the transaction page, the CA digitalcertificate is accessed by the client. The CA digital certificaterepresents a vouching by the CA (a trusted third party to thetransaction between the client and the server) that the content beingprovided to the client is originating from a server that matchesownership records for the accessed URL.

Some web pages draw content from multiple different servers through atechnology such as framing or native browser functionality (nativebrowser functionality is enabled by browser cross domain requestobjects). In a multi-frame web page, content is pulled together from aplurality of sources with a different network call being used for eachsource (multi-origin call). For example, a controlling frame of thetransaction page discussed above can draw content from one particularserver operated by an owner of the domain while another frame of thesame transaction page can draw content from another particular serveroperated by the owner of the domain or a server operated by a separateowner. When such a web page loads correctly, the image appears as asingle web page even though the content is assembled from the pluralityof servers.

When a client attempts to access a web page linked to a plurality ofcontent servers using the scheme described in the first paragraph, onlya portion of the web page will be loaded, or all of the web page will beloaded with only some of the content sources being authenticated, eitherof which represents a problem with the authentication process. In onecase, the resulting image is incomplete, while in the other case aportion of the servers providing the data to the client areunauthenticated, presenting a security hole. The disclosure that followssolves this and other problems.

SUMMARY OF THE INVENTION

The following is a summary of the invention in order to provide a basicunderstanding of some aspects of the invention. This summary is notintended to identify key/critical elements of the invention or todelineate the scope of the invention. Its sole purpose is to presentsome concepts of the invention in a simplified form as a prelude to themore detailed description that is presented later.

In one example, a system for authenticating domains operates byauthenticating a first domain and the extensions that make up the URI ofan initial or primary Internet network call. Thereafter, the system canenable the owner of the first domain to make assertions or statementsabout additional domains and URIs that make up the rest of the web page,session or application. Additional aspects and advantages of thisinvention will be apparent from the following detailed description ofpreferred embodiments, which proceeds with reference to the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a domain based authentication system.

FIG. 2 illustrates a setup configuration process in one example of anauthentication server that utilizes principles described with referenceto FIG. 1.

FIGS. 3A-B illustrate one example of a client using the authenticationserver subsequent to the setup configuration of FIG. 2 in a multi-domainauthentication process.

FIG. 4A-B illustrates a different example of a client using theauthentication server subsequent to the setup configuration of FIG. 2 ina multi-domain authentication process.

FIG. 5 is a flow chart illustrating a process performed by a firstAuthentication Authority server from FIGS. 3A-4B.

FIG. 6 is a flow chart illustrating a process performed by a secondAuthentication Authority server from FIGS. 3A-4B.

FIGS. 7-22 illustrate another example of a domain based authenticationsystem.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS Overview of theApplication Before Referring to the Figures

Authenticated Domains is an Internet based system to authenticateidentity and use rights for groups of interacting domains, such thatthey may be operated on as fused aggregations across diverse origins,sequences, protocols, applications or devices.

In one implementation, Authenticated Domains can authenticate a browsersession from the first page to the last, across both HTTP and HTTPSprotocols, as one. In another implementation, Authenticated Domains canenable a controlling frame in a web page to vouch for the other networkcalls that make up the rest of the web page (to address a problem withCertificate Authority certificates where only the controlling frame isauthenticated and other network calls on the web page are not.) In yetanother implementation, Authenticated Domains can authenticate amulti-application, multi-protocol and multi-origin series of domain andURI based network calls, such as an email, that includes advertisers andlinks to the email sender's web site, in a fused group as one.

Authenticated Domains operates by authenticating the domain and theextensions that make up the URI of an initial or primary Internetnetwork call, and then enabling the initial or primary domain (in theURI), once authenticated, to make assertions or statements aboutadditional domains and URIs that make up the rest of the web page,session or application. Authenticated Domains enables stateful,persistent and portable management of fused aggregations ofAuthenticated Domains, individually or as groups, because their coreidentity, and associated trust and use rights are normalized withrespect to each other.

Authenticated Domains validates the ownership of a domain name usingmethods similar to how a Certificate Authority (CA) validates theownership of certificate, but to uniform and normalized standards in allcases. The domain and the validated ownership data, a core identity, arebound together and made available via a secure lookup service in theInternet. When an end user receives content called from an AuthenticatedDomain, a Client Verifier in the end user's system or browser detectsthe Authenticated Domain and performs a secure and independent lookup tothe Authenticated Domains Service in the Internet to obtain the verifiedcore identity of the domain, as well as attributes and assertions boundto the domain, and to verify that DNS is accurate for the network callsinvolved.

There are multiple categories or levels of Authenticated Domains.Higher-level Authenticated Domains must meet more rigorous ownershipvalidation standards, but they also gain higher-level trust and userights, such as vouching, fusing and ecommerce, which are in the form ofassertions or statements bound to the Authenticated Domain. One of thevalidation standards may be equal to the Extended Validation (EV)standard recently developed for EV CA certificates. AuthenticatedDomains defines and enforces these trust and use rights, depending onthe validation level and authenticated domain category, within thesystem, such that a lower-level Authenticated Domain cannot besubstituted for a higher-level Authenticated Domain.

In addition to defining trust and use rights for each category or levelof Authenticated Domain, trust and use rights between categories orlevels of Authenticated domains are also defined and system enforced.

Authenticated Domains may supplement or replace Certificate Authority(CA) certificates. Unlike CA certificates, Authenticated Domains providenear universal authentication coverage for all domain and URI basednetwork calls in the Internet, regardless of protocol, application ordevice. Also, unlike CA certificates, domain ownership validation isperformed to uniform standards in all cases with corresponding systemenforced trust and use rights, and Authenticated Domains operate inuniform and normalized ways as groups, across protocols, applications,time dimensions and devices. In some implementations, an AuthenticatedDomain may be bound to a standard digital certificate to create asynthetic equivalent of a CA certificate.

Authenticated Domains also enable browsers to expand EV-type services,from just EV CA certificate web pages, to all web pages, and to makethese services persistent and stateful across domains, sessions andapplications.

Authenticated Domains contain key computing properties, such as beingunique, normalized with respect to trust and use, generalized across anyInternet protocol, application or device, atomic such that they can beused in any combination, sequence or function without transforming,persistent with respect to owner identity and assertions, and revocable.As such, they are designed to be consumed programmatically by externalapplications and services, including security, directory, monitoring,access control, state, logging, ecommerce, publishing, advertising,rights management, transaction, and other services.

Authenticated Domains include one or more means to ensure DNS accuracyfor all network calls. It does this through a combination of existingand new DNS authentication services, a trusted DNS service and anindependent DNS Client Verifier.

In one implementation, the Client Verifier may be installed as a signedapplication on the end user's client device, or in another it may be a“clientless” browser application that is downloaded as needed. In oneimplementation malware security and other services may be added to theClient Verifier to verify that the end user is who they say they are,that the browser is safe and that the end user has appropriate accesspermissions.

In one implementation, the Authenticated Domains service may beconfigured using SAML federation, such that the end user may perform aSAML log-in to the Authentication Authority, which in turn acts as aSAML Identity Provider to create a SAML federation between the enduser's Client Verifier and the Authoritative Authentication Servers (butnot the end user itself). In such cases, the external applications andservices applications that consume Authenticated Domains results may becloud services that are federated with the Authenticated Domainsessions.

In certain implementations, Authenticated Domains may be implemented vianew and unique combinations of services that make up InternetCertificate Authority, Extended Validation Certificates, Domain NameServer (DNS), Remote Authentication Dial-In User Service (RADIUS) orDIAMETER authentication and Security Assertion Markup Language (SAML)authentication services.

FIG. 1 illustrates a domain based authentication system.

The system 100 includes software 7 operating on a client 8 having as abrowser or email application and software 9 operating on anauthentication authority computer 10. The software 7 and 9 interoperateto authenticate one or more domains in response to the client 8accessing a web resource of the domain. The system 100 can include othersoftware operating on other devices, such as software 5 operating onsome or all of the content servers 1, 2, and 11, to communicate with thesoftware 7 and 9 to facilitate the domain based authentication.

One benefit of the above-described domain based authentication isapparent when considering network resources that utilize framing ornative browser functionality. These technologies allow a client todisplay content from a plurality of servers on a single document, suchas the example web page 3, an email, or any other document. The exampleweb page 3 contains a controlling frame 17 to display content stored ona server 1 of a first domain. The controlling frame 17 is the frame ofthe web page 3 that displays the content of the accessed URL. The webpage 3 has additional frame 18 to display content from either adifferent server 2 of the first domain or a server 11 of a seconddifferent domain. In either case, an additional frame 18 display can beassociated with a different URL, for example, a URL of the same domainbut with a different extension or a URL of a different domain. When theweb page 3 is displayed, there will be included thereon content from aplurality of servers (whether those servers include 1 and 2, or 1 and11, or 1, 2, and 11).

The authentication software 7 and 9 performs a domain basedauthentication process in conjunction with the client accessing the URLof the web page 3. Thus, it should be understood that the authenticationis not limited to a specific server for which a certificate is installedthereon. The authentication of the first domain applies to all of theservers of the first domain (servers 1 and 2).

Similarly, the domain based authentication process can includeauthentication of a plurality of domains. For example, when theadditional frame 18 displays content from the server 11 of the seconddomain, the second domain can be authenticated during the authenticationprocess.

FIG. 2 illustrates a setup configuration process in one example of anauthentication server that utilizes principles described with referenceto FIG. 1.

The system 200 is a particular example of an authentication authorityserver 20A that utilizes the principles of domain based authenticationas described in FIG. 1. In the particular example described below, thesystem 200 configures the authentication authority (AA) server 20A toperform an authentication for a cross domain call, which occurs when aweb page draws content from a plurality of different domains. It shouldbe apparent that other examples can utilize domain based authenticationwithout necessarily authenticating for a cross domain call (such as amulti-origin call within a single domain).

In this example, an owner controls a content server 21 for a firstdomain with at least one web page 23. The web page 23 is a multi-frameweb page 23 with a first subset (one or more) of frames 28 to displaycontent of the first domain. The first subset 28 includes at least acontrolling frame corresponding to the URL of the web page 23, and mayalso include other frames corresponding to other particular URLs to becalled for displaying the web page 23. The web page 23 also includes asecond subset 29 (one or more) of frames to display content of a seconddomain. The second domain may be under control of a different owner,such as a business affiliate of the owner.

In process 51, an owner of a domain 32 applies with the AA server 20A toregister that first domain 32 with the AA. In response, the AA server20A formats an entry in a core identity database 24 for the owner. Theentry in the database 24 binds the first domain 32 with a particularAuthentication Object (AO) 31, a core identity 33 for the owner, and insome examples, a domain type 34. The AO 31 can contain credentials,realm data, pathID, digital certification or other provenance items toprovide the identity of the corresponding domain.

The domain type 34 represents a validation category of the first domain32. If the first domain 32 is listed as a higher level, then the firstdomain 32 will be authenticated using a more rigorous ownershipvalidation standard in process 51. One example of such a fixed ownervalidation standard used for authentication is the Extended Validation(EV) standard recently developed for EV CA certificates. AuthenticatedDomains defines and enforces these trust and use rights, depending onthe validation level and authenticated domain category, within thesystem, such that a lower-level Authenticated Domain cannot besubstituted for a higher-level Authenticated Domain. Validationstandards for other types can be more rigorous or less rigorous than theEV standard. In any case, the validation standard used for one domain ofa particular type is the same validation standard used for all otherdomains of that particular type. Therefore, the validation for anyparticular domain proceeds according to the fixed standards set for thedomain type to which the particular domain corresponds in the domaintype field 34 (this can be contrasted with prior systems that used adhoc validation standards on a per-server basis). In the system 200, alldomains are validated to a respective one of a defined plurality offixed standards as specified by the domain type field 34.

The domain type 34 also indicates the trust and use rights, where ahigher level type gains additional trust and use rights not available tolower level types. Examples of the trust and use rights provided to ahigher level domain type are vouching, fusing and ecommerce, which arein the form of assertions or statements in the owner assertion database25. A domain of a particular level can vouch for domains of thatparticular level or less, but not for domains of a higher level. As willbe explained later in more detail, a second domain vouched for by thefirst domain will be treated as fused with the first domain by consumingclient applications and services. In addition to defining trust and userights for each category or level of Authenticated Domain, trust and userights between categories or levels of Authenticated domains are alsodefined and system enforced.

The owner can also register particular Uniform Resource Identifiers(URIs) of the domain (such as a particular Uniform Resource Locator(URL) as shown in the FIG. 2, where the particular URL is the domain 32plus a particular extension) with the AA. Each registered particular URIis associated with a particular sub-AO 41A-N. These sub-AOs 41A-N cancorrespond to other web pages of the domain, for example, other webpages besides the web page 23, or to the same web page 23 but adifferent one of the first subset 28 of frames. The sub-AOs 41A-N cancontain credentials, realm data, path ID, digital certification or otherprovenance items to provide the identity of the corresponding particularURI.

For each particular URI provided to the AA server in process 51, the AAserver 20A formats a sub-entry in the database 24 to associate theparticular URL 42 A-N with a particular one of the sub-AO 41A-N. Thesesub-entries are bound to the same core identity 33 in the core identitydatabase 24. The sub-AO 41A-N can be used to uniquely identify anynetwork call to the domain. In process 52, the AA server 20A providesthe AO 31 and sub-AOs 41A-N from the database 24 to the content server21.

In process 53, which can occur after, before, or during processes 51 and52, the content server 21 updates the owner assertion database 25. Thedatabase 25 contains assertions vouched for by the owner, which can becontrasted from database 24, which contains assertions vouched for bythe AA. As one example, in process 53 the owner could vouch for aparticular URI of another domain (such as a particular URL 48 as shownin the FIG. 2, where the particular URL 48 is a different domain plus aparticular extension). The AA server 20A associates a sub-AO 49 with theparticular URL 48 in the database 25.

The AA server 20A may then provide an acknowledgement in process 54,which may or may not include the sub-AO 49. It should be understood thatthe content server 21 will configure the web page 23 to provide therelevant object (OA 31 or sub-AOs 41A-N) in response to a network callfor the corresponding network call to the content server 21. This mayinvolve building a table on the content server 21 to correlate eachobject (OA 31 or sub-AOs 41A-N) with a respective network call.

Having described the setup of the databases 24 and 25, the example willnow move onto FIGS. 3A-B to illustrate how the configured databases 24and 25 are utilized to authenticate domains in response to a clientrequest.

FIGS. 3A-B illustrate one example of a client using the authenticationserver subsequent to the setup configuration of FIG. 2 in a multi-domainauthentication process.

In process 60, a client 68, such as a browser or email application,attempts to access the web page 23 with the controlling frame 28 (FIG.2). In response, in process 61 the content server 21 sends content 63for frame 28 of the requested web page 23 as well as the correspondingobject (AO 31) for the controlling frame 28. In examples where thesubset of frames 28 includes other frames for the first domain besidesthe controlling frame 28, the response can also contain particular onesof the sub-AOs 41A-N that correspond to the accessed web page 23.

In the present example, the client 68 can embargo the content downloadedwith the AO 31 in a secure location until authentication is complete forthe domain of this content. In other examples, the client 68 can deferdownloading this content until the first domain is authenticated (thusat this time only the AO 31 and possibly one or more sub AOs would bedownloaded to the client 68 in the other examples).

The client 68 then locates a securely linked lookup, such as realmserver 69. The realm server 69 is associated with the client andconfigured to find, on a per lookup basis, a particular one of the AAservers 20A-N for the domain of the accessed URL. In the presentexample, the realm server 69 can operate according to the RADIUSprotocol. In other examples, the realm server 69 can operate accordingto the DIAMETER protocol.

The client 68 generates a checksum 98 based on a shared secret with therealm server 69. The checksum 98 will be used by the client 68 tocorrelate a received authentication response with this authenticationrequest.

In process 77, the client realm server 69 accesses the request 75 toanalyze the URL information 64 or the AO 31, or both. Based on theinformation from this analysis, the client realm server 69 uses RADIUSto identify the relevant server 20A of the AA servers 20A-N for thedomain of the URL information 64. The client realm server then forwardsthe objects 31/41A, the URL information 64, and the checksum 98 to theidentified AA server 20A.

The AA server 20A then extracts the AO 31 from the authenticationrequest and compares the extracted AO 31 to the database 24 to identifya corresponding entry. If the domain 32 (FIG. 2) in the correspondingentry matches the URL information 64 included in the request, then thefirst domain has been authenticated.

The AA server 20A also accesses the owner assertion database 25 to checkfor assertions made by the owner of the authenticated domain. In thiscase, the AA server 20A identifies the entry for the cross domain (FIG.2 shows this entry in database 25). The AA server 20A then extracts thesub-AO 49 and URL information 48 from the identified entry. It should beunderstood that, in other instances, there may be an assertion for thecross domain that is not necessarily in the form of a sub-AO. In theseother instances, rather than including the sub-AO 49 for the crossdomain, the AA server 20A would insert these assertions from thedatabase 25 into the response.

The AA server 20A then sends a response to notify the client that thefirst domain is authenticated in process 78. The response includes theextracted sub-AO 49, the URL information 48, and the checksum 98.

The client 68 analyzes the response from the AA server 20A to identifythe checksum 98 included therein. Based on the presence of the checksum98 in the response, the client 68 has verified that the receivedresponse correlates to the authorization request. In this case, sincethere is a match, the client 68 has the information that the firstdomain has been authenticated by the AA.

Referring now to FIG. 3B, in process 81 the client sends a secondauthorization request for the sub-AO 49. The second request includes thesub-AO 49, the URL information 48, and a checksum 99.

The client realm server 69 accesses the request 81 to analyze the URLinformation 48 or the sub-AO 49, or both. Based on the information fromthis analysis, the client realm server 69 uses RADIUS to identify arelevant one of the AA servers 20A-N for the domain of the URLinformation 48. As the first and second domains are different, there isa possibility that a different one of the AA servers 20A-N will beidentified. For ease of explanation, in this example the second requestis forwarded to a different one (20N as illustrated) of the AA servers20A-N. The client realm server then forwards the object 49, the URLinformation 48, and the checksum 99 to the identified AA server 20N inprocess 82.

The AA server 20N the compares the sub-AO 49 of the second request to acore identity database thereon. The comparison will elicit acorresponding core identity for the second domain. The AA server 20Nthen compares the URL information 48 from the second request with thedomain information in an entry for the corresponding core identity.Based on the comparison, the second domain has now been authenticated bythe AA. The AA server 20N can also verify that the URL/sub-AOcombination 48/49 included in the request matches a combination includedin the core identity database of the AA server 20N.

It should be understood that the processing of the second request isperformed to authenticate the second domain on the basis of coreidentity. Prior to the processing of the second request, the onlyvouching that has taken place for the URL of the second domain is thevouching by the owner for the first domain. Although the owner of thefirst domain has been authenticated, the vouching by such authenticatedowner in the database 25 has not been authenticated by the AA. Asexplained previously, the two databases 24 and 25 are logicallyseparated, with the former including core identity statements vouched bythe AA and the later containing statements vouched by the owner (but notnecessarily validated by the AA).

Having the core identity of the second domain now authenticated by theAA, in process 85 the AA server 20N can respond to the client 68 for thesecond authorization request. The response includes the authenticationresults 88 as well as a validation 89 of correspondence between theparticular sub-AO and the particular URL. As before, the response caninclude the checksum 99 to allow the client 68 to verify that thisresponse corresponds to the second authorization request.

In process 90, the client 68 can make a call to the server(s) 91 of thenow-authenticated cross domain. The client 68 receives back content forthe frame 29 corresponding to the URL of the second domain in process92. In other examples, the client 68 may have prefetched the content forthe frame 29 prior to authenticating the cross domain. In these otherexamples, the prefetched content is embargoed in a secure location onthe client 68 until the cross domain is authenticated.

After process 92, the client can now display the entire web page 23using content from both domains. Additionally, since the authenticationsby the AA were made on a domain level rather than a server level, theclient can also display any portions of the web page 23 drawn from anyservers of either domain.

It should be apparent that the client 68 may perform an additionalprocess to further verify the authentication results from the AA. Forexample, the client 68 can forward the authentication results to asecurity application operating a reputation database (typically thereputation database is operated by a different party than the AA).

It should be understood that the functions described above with respectto FIGS. 3A-B are performed by novel software distributed over theclient 68, some or all of the content servers of the domains (includingillustrated content servers 21 and 91), the realm server 69, and the AAservers 20A-N.

FIG. 4 illustrates a different example of a client using theauthentication server subsequent to the setup configuration of FIG. 2 ina multi-domain authentication process.

The example described with reference to FIG. 4 includes componentsprogrammed with the SAML protocol, rather than components configuredwith the RADIUS protocol as described with FIGS. 3A and 3B. It should beunderstood that the setup process described in FIG. 2 is general andapplicable to both the example of FIGS. 3A-B and the example of FIG. 4.

In process 160, a client 168, such as a browser or email application,attempts to access the web page 23 with the controlling frame 28 (FIG.2). In response, in process 161 the content server 21 sends content 63for frame 28 of the requested web page 23 as well as the correspondingobject (AO 31) for the controlling frame 28.

The client 168 analyzes the response and, in response to detecting theAO 31, logs into the SAML IdP server 169. This login process can involveclearing cached data or anything that is insecure before the login,particularly if the client 168 is a browser. The login could alsoauthenticate the end user by verifying that the network location of theclient 168 matches a known location for a client 168 operated by thisuser. The login could also utilize multiple access levels, wheredifferent users are given different authorities once logged in. Once theclient 168 is logged into the SAML IdP server 169 these two devices arefederated, and the client 168 can provide the AO 31 and URL information64 to the SAML IdP server 169 in process 175.

Thereafter, the AA can then authorize the client 168 to be federated toone, any, or all of the AA servers 20A-N using the SAML IdP server 169.For example, the SAML IdP server 169 could federate the client 168 withonly the particular one of the AA servers 20A-N that corresponds to theAO 31 in one example, or all of the AA servers 20A-N in another example.The federation secures the communications independently of the checksumscheme described previously.

After federation is complete, the process continues with the AA server20A receiving the initial authentication request in process 177,performing similar authentications as described previously beforeresponding in process 178. Referring to FIG. 4B, processes 181, 182, and183 associated with the second authentication are conducted in a similarfashion as the second authentication described earlier with respect toFIG. 3B.

One difference between the system 300 and the system 200 arises if theclient 68 utilizes a security application separate from the AA. In thepresent system 300, the SAML IdP server 169 can federate in any otherdevices specified by the client 168. For example, the SAML IdP servercould federate in a security application operating a reputation databaseto monitor the authentication process and validate the results as theyare generated.

It should be understood that the functions described above with respectto FIGS. 4A-B are performed by novel software distributed over theclient 68, some or all of the content servers of the domains (includingillustrated content servers 21 and 81), the SAML IdP server 169, and theAA servers 20A-N.

FIG. 5 is a flow chart illustrating a process performed by a firstAuthentication Authority server from FIGS. 3A-4B.

In block 500, the AA server receives an authentication request includingan authentication object and information specifying a network resource.In block 501, the AA server compares the first request to a coreidentity database. If the comparison indicates that the network resourcedoes not correspond to a core identity of the authentication object indiamond 502, then in block 503A the AA server sends a message indicatingthat the network resource is unauthenticated.

If there is a match in diamond 502, then in block 503B the AA serverauthenticates the first domain. In block 504, the AA server accessesassertions made by the core identity of the first domain. If noauthentication objects are found for any other domains in the assertionsin diamond 505, then in block 506A the AA server sends a messageindicating that the first domain is authenticated.

If an assertion for a second different domain is found in diamond 505,then in block 506B the AA server sends a message indicating that thefirst domain is authenticated that includes the assertion for the seconddomain in the message. The assertion can be an authentication object forthe second domain. It should be understood that, depending on the numberof other domains the core identity of the first domain has vouched for,there could be more than one assertion included in the message.

FIG. 6 is a flow chart illustrating a process performed by a secondAuthentication Authority server from FIGS. 3A-4B.

It should be understood that the processes described below can beperformed by the same server performing the processes described withrespect to FIG. 5A. The server that receives the authentication requestfor the core identity of the second different domain may or may not bedifferent than the server that received the authentication request forthe core identity of the first domain, as described in more detailearlier. For ease of explanation the term “AA server” will again beused, but it should be understood that this refers to “the same oranother” AA server.

In block 600, the AA server receives an authentication request includingan assertion for a second domain and information specifying a networkresource in the second domain. In block 601, the AA server compares therequest to a core identity database. If there is no match in diamond602, then in block 603A the AA server sends a message indicating thatthe network resource specified in the request is unauthenticated.

If there is a match in diamond 602, then in block 603B the AA serverauthenticates the second domain. The AA server sends a messageindicating that the first domain is authenticated in block 604.

FIGS. 7-22 illustrate another example of a domain based authenticationsystem. The text included within the boxes themselves describes thisexample.

In an example, there is provided a method of authentication toauthenticate groups of domains holistically as one. The domains can begrouped based on their making up a web page (e.g., made up of frames),an online session, a set of interacting applications or interactingdevices. The domains that make up a group can be multi-origin (i.e.,different domains such that content is from different sources).

In an example, ownership of domain names is validated by a single andauthoritative entity and the validating entity is also theAuthentication Authority. Domain ownership validation can be done to oneor more fixed Owner Validation Standards. Each Owner Validation Standardcan equate to a specific Authenticated Domain Type or category. Eachparticular Authenticated Domain Type defines a particular defined levelof Ownership Validation. Owner Validation Standards for theAuthenticated Domain Types can range from high and rigorous to low andless rigorous. Each Authenticated Domain Type can be assigned aparticular Trust and Use Category. The assigned Trust and Use Categoryfor an Authenticated Domain can also define specific trust and useAssertions. The Authentication Authority controls and enforces saidtrust and use Assertions such that the owner of each AuthenticatedDomain has access only to those trust and use assertions assigned to itsAuthenticated Domain Type. The trust and use relationship for multipleAuthenticated Domains of a specific Authenticated Domain Type can beequivalent and normal, and the Trust and Use relationships betweenAuthenticated Domains of different Authenticated Domain Types aredefined and fixed.

In one example, the Authentication Authority vouches for the CoreIdentity of an Authenticated Domain in all cases. The Core Identity canequate to a binding of the Authenticated Domain, the AuthenticatedDomain Type and the specific Domain Owner data as defined by theAuthenticated Domain Type. The Domain Owner may make Assertions aboutthe Authenticated Domain, but not about the Core Identity of theAuthenticated Domain. Such Assertions can be governed by the Trust andUse Category as set by the Authentication Authority of the AuthenticatedDomain making the Assertion.

The Domain Owners can implement, remove, update and change saidAssertions via an Authentication Authority provided and controlled setof Statements. The Statements are governed by those allowed by theAuthentication Authority for each Trust and Use Category. AuthenticatedDomains of a high Trust and Use Category have rights to Statements thatassert higher levels of trust and functionality than those available toAuthenticated Domains of a lower Trust and Use Category. A high levelAuthenticated Domain may execute Statements that are Assertions aboutequal or lower level Authenticated Domains, or about themselves. TheStatements may include Assertions that extend or assert aspects of theIdentity, Trust, Use or other attributes of one Authenticated Domain toone or more other Authenticated Domains, (but not about the CoreIdentity of the Authenticated Domain). Said other Authenticated Domainsmay be Authenticated Domains that are owned by other Domain Owners orare serviced by systems and sources other than the Authenticated Domainmaking the Assertions. The Assertions can include Statements that Assertthat another Authenticated Domain should be considered equal to theAsserting Authenticated Domain in terms of identity, trust, use or otherattributes, such that the Authenticated Domain may be treated as Fusedby consuming Client Applications and Services with respect to theattributes of these Assertions.

The Client Applications and Services include network calls to contentfrom multiple origins. Client Applications and Services and externalapplications and services can operate on and treat groups ofAuthenticated Domains as one. The operations and treatment of a group ofAuthenticated Domains can be the same as the operation and treatment ofone of the Authenticated Domains.

State information can be maintained across groups of AuthenticatedDomains. The Authentication Domains that provide data making up a webpage, a session, interacting applications, services or devices.

A Content Server can send an Authentication Object to a Client inresponse to a Client access, to authenticate the Authenticated Domainsending the content, along with the content. The Authentication Objectcan contain credentials, Realm data, PathID, digital certificates orother provenance items to prove the identity of the source AuthenticatedDomain sending the content.

Data relating to the Authentication Object is securely maintained at anAuthoritative Realm Server, which can be part of and under the controlof the Authentication Authority. For example Realm data and Path ID fromthe Authentication Object can equate to a Uniform Resource Indicator(URI) or Uniform Resource Locator (URL).

The Security Assertion Markup Language (SAML) protocol and standards canbe used to federate a Client Verifier with the Authentication Authority.Similarly, the SALM protocol and standards can be used to securelyfederate said Client Verifier and said Authentication Authority withsaid Authoritative Realm Servers. The Authoritative Realm Servers arethe authoritative source for an Authenticated Domain's Core Identity(which is maintained exclusively by the Authentication Authority) andStatements and Assertions about the Authenticated Domain (which aremaintained by the Authenticated Domain Owner). In another example, aRemote Access Dial Up Service (RADIUS) service or its successor DIAMETERcan be used to authenticate an Authenticated Domain, used by a ContentServer, to a Client Verifier.

In one example, the Content Server can send an Authentication Object tothe Client Verifier to authenticate that it came from a specificAuthenticated Domain. The Client Verifier forwards said AuthenticationObject as an Authentication Request to a Client Realm Server, which isunder the control of the Authentication Authority, along with a Checksumthat is known between the Client Verifier and the Client Realm Server.The Client Realm Server authenticates via said Checksum that theAuthentication Object came from the Client Verifier. The Client RealmServer uses RADIUS to find and securely communicate with theAuthoritative Realm Server that can service the Authentication Request.The Client Realm server creates a new Checksum and sends it along withthe Authentication Request to the Authoritative Realm Server.

Continuing the example of the previous paragraph, the AuthoritativeRealm Server determines if the Authentication Object is from theAuthenticated Domain that claimed to send the content by comparing theCredential, Digital Certificate or other Provenance Items, in theAuthentication Object with Credentials, Digital Certificates or otherProvenance Items for the Realm and PathID maintained at theAuthoritative Realm Server. The Authoritative Realm Server sends theResults of the Authentication Request to the Client Verifier. TheAuthoritative Realm Server sends the new Checksum generated by theClient Realm Server to the Client Verifier along with the Results of theAuthentication Request to authenticate the Authoritative Realm Server tothe Client Verifier. The Results sent by the Authoritative Realm Serverinclude Core Identity data about the Authenticated Domain sendingcontent from the Content Server. The Results are used by the ClientVerifier, End Use, Client Applications or Services or Control Apps toverify if the content was sent by the Authenticated Domain Additionallythe Client Verifier, Control Apps, Client Applications and Services orthird party applications and data bases can be used to determine if thecontent may be trusted or used in a specific context.

Continuing the example of the previous paragraph, the Results mayinclude additional Authentication Objects, Statements and Assertionssent by the Authoritative Domain Server for the primary AuthenticatedDomain, to vouch for network calls to secondary Authenticated Domainsthat were part of the total content sent by Content Server, along withthe primary or controlling Authenticated Domain. The Client Verifieriteratively authenticates the secondary Authentication Objects, suchthat multiple Core Identities are authenticated as a group. The ClientVerifier, and helper applications, can then treat the grouped or fusedAuthenticated Domains, and Statements and Assertions about them as one.

It should be understood that entities may maintain and communicate theircorporate or IT structure via Statements and Assertions that theymaintain directly within an Authoritative Realm Server, where theAuthentication Authority maintains the Core Identities for theAuthenticated Domains involved and the Authoritative Realm Server. Anetwork address, such as an address made up of tupels or an ordered listof elements, can be represented by a Top Level Domain where the domainnames always exactly equal the network address. Said domain name of thecore identity database is an Authenticated Domain. Client Verifiers andhelper applications, such as security and reputation services, can treatnetwork addresses as non-variable Authenticated Domain Names that alwaysresolve to one and only one network address. Said network addressAuthenticated Domains are treated by Client Verifiers, overlay security,reputation and helper applications, as normatively equal to traditionaldomain based Authenticated Domains.

In one example, the Authentication Authority can track and report on theUsage or Instances of an Authenticated Domain authentication. The Usageor Instance of the Authenticated Domain is to call a logo, brand orother entity identifying mark. A transaction fee is tabulated every timean Authenticated Domain is authenticated.

In one example, a Uniform Resource Identifier (URI) or Uniform ResourceLocator (URL) is defined as a subset of an Authenticated Domain. A fullyqualified domain name in a URI or URL is defined as the AuthenticatedDomain in a URI or URL that includes an Authenticated Domain. Extensionsto the Authenticated Domain Name can include prefixes and suffixes tothe fully qualified domain name in an Authenticated Domain. TheExtensions denote defined or well known services. The fully qualifieddomain name can be equal to the Realm of an Authenticated Domain and theExtension can be equal to the PathID of an Authenticated Domain Name.The Realm and PathID equal the URL or URI of a unique network call, suchas a client request for content to a Content Server or the multi-originnetwork calls that may be included the Content Servers response to theinitial content request, are uniquely identifiable and atomic.

The URI or URL, in the form of a Realm and PathID, may be assignedunique identifying Credentials, Digital Certificates, Provenance Items,Assertions or Statements. Well known services equate to a specifictechnical or use context.

In an example, multi-origin authentication is complete after some or allparties successfully authenticate.

In one example, CA issued digital certificates can be re-validated toconform to Authenticated Domain standards. The re-validated CA issueddigital certificates can operate as and be equal to AuthenticatedDomains.

In one example, the Client Verifier (also “client”) or helperapplications can maintain a list of Authenticated Domains that are alsomembers of a pre-vetted group of domains. The Client Verifier can be a“clientless” browser helper application, that is downloaded by theAuthentication Authority, to an end user browser when the end user logsin to the Authentication Authority to begin an Authenticated Domainssession. The Authentication Authority can perform checks and scans ofthe end user browser before downloading the “clientless” ClientVerifier. The Authentication Authority can verify that the end user iswho they say they are, that the end user has certain access rights tospecific content called by Authenticated Domains or that the browser isfree of malware, cached data or executables or other security threatsprior to downloading the “clientless” Client Verifier. TheAuthentication Authority can remove all or specific traces of the“clientless” Client Verifier or data or executables created by anAuthenticated Domains session, at the end of the session. It should beunderstood that the Authentication Authority system can be configured torevoke an authentication at any time by informing the client verifierthat a particular domain is no longer authenticated. The AuthenticationAuthority system can also change its databases at any time to preventany further authentications for a particular domain for any reason.

It will be apparent to those having skill in the art that many changesmay be made to the details of the above-described embodiments withoutdeparting from the underlying principles of the invention. The scope ofthe present invention should, therefore, be determined only by thefollowing claims.

Most of the equipment discussed above comprises hardware and associatedsoftware. For example, the equipment is likely to include one or moreprocessors and software executable on those processors to carry out theoperations described. We use the term software herein in its commonlyunderstood sense to refer to programs or routines (subroutines, objects,plug-ins, etc.), as well as data, usable by a machine or processor. Asis well known, computer programs generally comprise instructions thatare stored in machine-readable or computer-readable storage media. Someembodiments of the present invention may include executable programs orinstructions that are stored in machine-readable or computer-readablestorage media, such as a digital memory. We do not imply that a“computer” in the conventional sense is required in any particularembodiment. For example, various processors, embedded or otherwise, maybe used in equipment such as the components described herein.

Memory for storing software again is well known. In some embodiments,memory associated with a given processor may be stored in the samephysical device as the processor (“on-board” memory); for example, RAMor FLASH memory disposed within an integrated circuit microprocessor orthe like. In other examples, the memory comprises an independent device,such as an external disk drive, storage array, or portable FLASH keyfob. In such cases, the memory becomes “associated” with the digitalprocessor when the two are operatively coupled together, or incommunication with each other, for example by an I/O port, networkconnection, etc. such that the processor can read a file stored on thememory. Associated memory may be “read only” by design (ROM) or byvirtue of permission settings, or not. Other examples include but arenot limited to WORM, EPROM, EEPROM, FLASH, etc. Those technologies oftenare implemented in solid state semiconductor devices. Other memories maycomprise moving parts, such as a conventional rotating disk drive. Allsuch memories are “machine readable” or “computer-readable” and may beused to store executable instructions for implementing the functionsdescribed herein.

A “software product” refers to a memory device in which a series ofexecutable instructions are stored in a machine-readable form so that asuitable machine or processor, with appropriate access to the softwareproduct, can execute the instructions to carry out a process implementedby the instructions. Software products are sometimes used to distributesoftware. Any type of machine-readable memory, including withoutlimitation those summarized above, may be used to make a softwareproduct. That said, it is also known that software can be distributedvia electronic transmission (“download”), in which case there typicallywill be a corresponding software product at the transmitting end of thetransmission, or the receiving end, or both.

Having described and illustrated the principles of the invention in apreferred embodiment thereof, it should be apparent that the inventionmay be modified in arrangement and detail without departing from suchprinciples. We claim all modifications and variations coming within thespirit and scope of the following claims.

1. A system, comprising: an authentication authority computing deviceencoded with instructions that, if executed, result in: accessing anauthentication request including a first authentication object of afirst domain and containing information specifying a network resource ofthe first domain; comparing the request for the first domain to a coreidentity database; correlating the first domain to a particular one of aplurality of validation standards; authenticating the first domainaccording to the comparison and according to the correlated standard; ifthe first domain is authenticated, accessing assertions made by the coreidentity of the first domain; sending messaging to a client indicatingthat the first domain is authenticated, wherein the messaging provides asecond different authentication object for a second different domain;wherein the plurality of validation standards includes at least a firstvalidation standard and a second validation standard, and wherein if agiven domain is authenticated according to the first standard then theauthentication authority computing device provides a computing device ofthe first domain with a grammar that includes at least one command forthe owner of the given domain to submit assertions with respect to anetwork resource of another domain.
 2. The system of claim 1, whereinthe authentication authority computing device is encoded withinstructions that, if executed, result in: accessing a subsequentlyreceived authentication request including the second authenticationobject of the second domain and information specifying a networkresource of the second domain; comparing the subsequently receivedauthentication request for the second domain to the same or another coreidentity database; authenticating the second domain according to thecomparison; and \ if the second domain is authenticated, sendingmessaging indicating that the second domain is authenticated.
 3. Thesystem of claim 2, further comprising: the client to display an entiredocument comprising at least one frame corresponding to the networkresource of the first domain and at least one frame corresponding to thenetwork resource of the second domain; wherein at the time the entiredocument is displayed, ownership of both domains has been authenticatedby the authentication authority.
 4. The system of claim 2, wherein theauthentication authority computing device comprises a plurality ofdifferent servers.
 5. The system of claim 2, further comprising: theclient encoded with instructions that, if executed, result in:generating a checksum for each authentication request; sending theauthentication requests with the checksums included therein to a RADIUSserver; and receiving the messaging and correlating authenticationresults included therein to a respective one of the authenticationrequests by analyzing the messaging for the checksums.
 6. The system ofclaim 2, further comprising: the client encoded with instructions that,if executed, result in: receiving the messaging and extracting domainauthentication results therefrom; sending the domain authenticationresults to a reputation based authentication service for verification.7. The system of claim 2, further comprising: the client encoded withinstructions that, if executed, result in: federating with a SecurityAssertion Markup Language (SAML) Identity Provider (IdP) server; andsignaling the SAML IdP server to identify a particular reputation basedauthentication service device to be federated with the client and theSAML IdP server.
 8. The system of claim 4, further comprising: a realmserver with instructions that, if executed, result in: analyzing theauthentication objects included in the authentication requests;identifying a particular one of the plurality of servers for each of theauthentication requests based on results of the analyses; and forwardingthe authentication requests according to the identification.
 9. Thesystem of claim 4, further comprising: a SAML Identity Provider (IdP)server with instructions that, if executed, result in: analyzing thefirst authentication object to identify a particular one of theplurality of servers; federating the identified particular server withthe client; analyzing the second authentication object to identifyanother particular one of the plurality of servers; and federating theidentified another particular server with the client, wherein thefederations are sequential.
 10. The system of claim 2, furthercomprising: a content server with instructions that, if executed, resultin: receiving the first authentication object from the authenticationauthority computing device; generating a table entry on the contentserver to associate the first authentication object with a particularnetwork call; and providing the first authentication object from thetable entry to the same or another client whenever the particularnetwork call is received.